System and method for monitoring a state associated with a general packet radio service support node

ABSTRACT

A method for monitoring a state associated with a support node is provided that includes receiving one or more communication flows from a first support node, the first support node communicating a message to a second support node that propagates through a loadbalancer. Activity associated with the second support node is then monitored. The method also includes removing one or more communications tunnels associated with the second support node when the second support node does not respond to the message communicated by the first support node.

TECHNICAL FIELD OF THE INVENTION

This invention relates in general to the field of communications andmore particularly to a system and method for monitoring a stateassociated with a general packet radio service support node.

BACKGROUND OF THE INVENTION

Networking architectures have grown increasingly complex incommunications environments. In addition, the augmentation of clients orend users wishing to communicate in a network environment has causedmany networking configurations and systems to respond by adding elementsto accommodate the increase in networking traffic. Communication tunnelsmay be used in order to establish or to gain access to a network,whereby an end user or an object may initiate a tunneling protocol byinvoking a selected location or a network node. The network node orcentral location may then provide a platform that the end user may useto conduct a communication session.

As the subscriber base of end users increases, proper routing andefficient management of communication sessions and data flows becomeeven more critical. Some communication sessions or tunnels are stagnantin a network and remain unused by end users. Such dormancy may be causedby network providers attempting to offer always-on service to itsclients or customers. These inactive channels may decrease throughputand inhibit the flow of network traffic, causing congestion orbottlenecks in the system. Additionally, the overwhelming number ofstale communications tunnels may decrease bandwidth capabilities as aburdened component is required to maintain communication sessions ortunnels that are not being used. This further prohibits the network fromoffering additional communication tunnels or accommodating additionalend users. Such a scenario reflects poor resource allocation in thenetwork and operates to tax network equipment with tasks that aregenerally inconsequential to communications in the architecture.

SUMMARY OF THE INVENTION

From the foregoing, it may be appreciated by those skilled in the artthat a need has arisen for an improved communications approach thatprovides for a reduction in the burden placed on a loadbalancerassociated with communications between two end points or nodes. Inaccordance with one embodiment of the present invention, a system andmethod for monitoring a state associated with a support node areprovided that greatly reduce disadvantages and problems associated withconventional loadbalancing techniques.

According to one embodiment of the present invention, there is provideda method for monitoring a state associated with a support node thatincludes receiving one or more communication flows from a first supportnode, the first support node communicating a message to a second supportnode that propagates through a loadbalancer. Activity associated withthe second support node is then monitored. The method also includesremoving one or more communications tunnels associated with the secondsupport node when the second support node does not respond to themessage communicated by the first support node.

Certain embodiments of the present invention may provide a number oftechnical advantages. For example, according to one embodiment of thepresent invention a communications approach is provided that allows aloadbalancer to clear or otherwise remove communication sessions ortunnels that are not being used. This reduction in responsibility forthe loadbalancer operates to increase throughput and bandwidth becausethe loadbalancer is relieved from a significant amount of dormanttunnels. Accordingly, the loadbalancer may be involved in only activecommunication tunnels to allow maximum bandwidth capabilities to bereached.

Yet another technical advantage of one embodiment of the presentinvention is the result of the removal of communication tunnels that arestagnant in the network. This flushing of communication tunnels operatesto better allocate network resources because only active data pathwaysare maintained by the network equipment. This further simplifies thenetwork configuration and allows for a more efficient use of networkcomponents and elements. Certain embodiments of the present inventionmay enjoy some, all, or none of these advantages. Other technicaladvantages may be readily apparent to one skilled in the art from thefollowing figures, description, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

To provide a more complete understanding of the present invention andfeatures and advantages thereof, reference is made to the followingdescription, taken in conjunction with the accompanying figures, whereinlike reference numerals represent like parts, in which:

FIG. 1 is a simplified block diagram of a communications system forcommunicating data in a loadbalancing environment in accordance with oneembodiment of the present invention;

FIG. 2 is a simplified block diagram of a table included within aloadbalancer of the communication system; and

FIG. 3 is a flowchart illustrating a series of example steps associatedwith a method for communicating data in a loadbalancing environment.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a simplified block diagram of a communication system 10 forcommunicating data in a network environment. Communication system 10includes an end user 12, a radio access network (RAN) 14, multipleserving general packet radio service (GPRS) support nodes (SGSN) 18 aand 18 b, and an internet protocol (IP) network 20. Additionally,communication system 10 includes a loadbalancer 26 and multiple gatewayGPRS support nodes (GGSNs) 30 a–b. Loadbalancer 26 may include a table28 operable to store data associated with communication sessionsinvolving SGSNs 18 a and 18 b and GGSNs 30 a and 30 b.

Communication system 10 may be generally configured or arranged torepresent a 2.5G communication architecture applicable to a GlobalSystem for Mobile (GSM) environment in accordance with a particularembodiment of the present invention. However, the 2.5G architecture isoffered for purposes of example only and may alternatively besubstituted with any suitable networking protocol or arrangement thatprovides a communicative platform for communication system 10. Forexample, communication system 10 may cooperate with any version of aGPRS tunneling protocol (GTP). This may also be inclusive of 3Garchitectures that provide a configuration allowing loadbalancer 26 toglean some piece of information associated with a selected GSN.

In accordance with the teachings of the present invention, communicationsystem 10 operates to alleviate the burden on loadbalancer 26 byremoving communication tunnels that are dormant in communication system10. These stagnant communication tunnels may be cleared such that theyno longer tax loadbalancer 26. The removal of inactive communicationstunnels may be accomplished by loadbalancer 26 passively monitoring thespecification defined path verification messages that may be sentbetween SGSNs 18 a and 18 b and GGSNs 30 a and 30 b. Monitoringcommunication sessions, such as path verification echo messages forexample, may allow loadbalancer 26 to detect a failed GSN by keepingtrack of echo activity.

A GSN failure may be detected when mandatory echoing is not seen for aperiod of time or the recovery information that may be included in theecho messages changes. Loadbalancer 26 may respond to these scenarios bycleaning up persistent records for GTP tunnels associated with mobileusers on the failed GSNs. This may be accomplished in cooperation withtable 28 without requiring subscriber heartbeats, keepalives, or anyother signaling protocol or message used to assist in this execution.Thus, an accurate session table 28 may be used to conserve resourcesassociated with loadbalancer 26 by cleaning up failed or inconsequentialcommunication sessions in a timely manner. Additionally, by notrequiring subscriber keepalives or other elements, air interfaces may beconserved to increase bandwidth for communication system 10.

The passive monitoring approach provided by loadbalancer 26 allows aflushing or clearing of communication sessions or tunnels that are notbeing used. This data structure optimization in the loadbalancer 26operates to increase throughput because a significant amount of deadtunnels may be removed from loadbalancer 26. Accordingly, loadbalancer26 may be involved in only active communication tunnels. The flushing ofcommunication tunnels may also operate to better allocate networkresources because only active data pathways are maintained by thenetwork equipment. This further simplifies the network configuration ofcommunication system 10 and allows for a more efficient use of networkcomponents and elements.

End user 12 is a client or a customer wishing to initiate acommunication tunnel in communication system 10 via IP network 20. Enduser 12 may be inclusive of devices used to initiate a communication,such as a computer, a personal digital assistant (PDA), a laptop orelectronic notebook, a telephone, a mobile station, or any other device,component, element, or object capable of initiating voice or dataexchanges within communication system 10. End user 12 may also beinclusive of a suitable interface to the human user, such as amicrophone, a display, a keyboard, or other terminal equipment (such asfor example an interface to a personal computer or to a facsimilemachine in cases where end user 12 is used as a modem). End user 12 mayalso be any device that seeks to initiate a communication on behalf ofanother entity or element, such as a program, a database, or any othercomponent, device, element, or object capable of initiating a voice or adata exchange within communication system 10. Data, as used herein inthis document, refers to any type of numeric, voice, or script data, orany type of source or object code, or any other suitable information inany appropriate format that may be communicated from one point toanother.

RAN 14 is a communications interface between end user 12 and SGSNs 18 aand 18 b. RAN 14 may comprise a base transceiver station and a basestation controller. The communications interface provided by RAN 14allows data to be exchanged between end user 12 and any number ofselected elements within communication system 10. RAN 14 facilitates thedelivery of a request packet generated by end user 12 and the receptionof information sought by end user 12. RAN 14 is only one example of acommunications interface between end user 12 and SGSNs 18 a and 18 b.Other types of communications interfaces may be used for any particularnetwork design.

IP network 20 represents a series of points or nodes of interconnectedcommunication paths for receiving and transmitting packets ofinformation that propagate through communication system 10. IP network20 offers a communicative interface between end user 12 and selectedGGSNs 30 a–b and may be any local area network (LAN), wireless localarea network (WLAN), metropolitan area network (MAN), wide area network(WAN), or any other appropriate architecture or system that facilitatescommunications in a network environment. IP network 20 implements a userdatagram protocol (UDP)/internet protocol (UDP/IP) communicationlanguage protocol in a particular embodiment of the present invention.However, IP network 20 may alternatively implement any other suitablecommunication protocol for transmitting and receiving data packetswithin communication system 10.

SGSNs 18 a and 18 b and GGSNs 30 a and 30 b cooperate in order tofacilitate a communication session involving end user 12. GGSNs 30 a–bare communications nodes operating in a GPRS environment that may beworking in conjunction with multiple SGSNs 18 a and 18 b to provide acommunications medium in a GPRS service network environment forcommunicating high-speed data exchanges within communication system 10.GGSNs 30 a and 30 b may be inclusive of a walled garden or any othersuitable mechanism that a network operator may choose to implement inproviding some connectivity for the network. GPRS represents apacket-based data bearer service for communication services that may bedelivered as a network overlay for any type of suitable networkconfiguration or platform. GPRS generally applies packet-radio andpacket switching principles to transfer data packets in an efficient waybetween GSM elements or units and external packet data networks. Packetswitching occurs when data is split into packets that are transmittedseparately and then reassembled at a receiving end. GPRS may supportmultiple internet communication protocols and may enable existing IP,X.25, or any other suitable applications or platforms to operate overGSM connections.

Loadbalancer 26 is an element or a device that receives requests andthen distributes those requests to the next available server or node.The available server or node may be any computer, component, or deviceon a network that manages network resources or that processes data. Suchloadbalancing decisions may be executed based on suitable algorithms orsoftware provided in loadbalancer 26. Loadbalancer 26 may also includehardware and/or software for directing signaling and data information incommunication system 10.

Loadbalancer 26 may also perform other suitable loadbalancing tasks,such as dividing of the amount of work that an element has to do betweentwo or more elements such that more work gets done in the same amount oftime and, in general, end user 12 may be served more quickly.Loadbalancer 26 may include any appropriate hardware, software, acombination of both, or any appropriate component, device, element, orobject that suitably manages information traffic in a networkenvironment. Additionally, any of the operations of SGSNs 18 a–b orGGSNs 30 a–b may be assisted by loadbalancer 26 where appropriate and inaccordance with particular needs.

In operation, loadbalancer 26 may execute loadbalancing decisions forselected GGSNs 30 a–b. Loadbalancer 26 may recognize a substantialnumber of dormant communication tunnels that have been established inassociation with GGSNs 30 a and 30 b and SGSNs 18 a and 18 b. As thenumber of end users or subscribers grow, it becomes necessary todistribute GTP tunnels across several GGSNs 30 a and 30 b. Thisloadbalancing may be accomplished by loadbalancer 26 which assigns eachGTP tunnel to a particular GGSN 30 a or 30 b. This assignment may bemaintained as a persistent record in loadbalancer 26 and used to deliversubsequent GTP messages for this tunnel to an assigned GGSN 30 a or 30 band to accurately determine the number of sessions on a particular GGSNin providing optimal loadbalancing.

Some network providers may seek to offer always-on services to endusers. Using such a plan, end user 12 may bring up a GTP tunnel and sendno traffic over that tunnel for long periods of time (note that most GTPprotocols may not have per-tunnel keepalive mechanisms). While thetunnel is open (whether active or inactive), loadbalancer 26 maycontinue to store the persistent record of its GSN assignment. However,in cases where any GSN fails, loadbalancer 26 may be wasting itsresources on stagnant communication tunnels that remain inactive in thearchitecture.

Loadbalancer 26 obviates the problem of inactive tunnels by makingitself aware of failed GSNs or communication tunnels that are no longerneeded. This detection by loadbalancer 26 operates to conserve networkresources and to avoid leaking memory as loadbalancer 26 checks on thestatus or health of each GSN to which it is connected. This may beaccomplished by passively monitoring communication flows such as echocommunications or recovery information element changes in communicationmessages between nodes in the network. In this manner, loadbalancer 26may keep track of active GGSNs 30 a or 30 b and active SGSNs 18 a and 18b. Information relating to this monitoring may be stored in any suitablelocation, such as table 28 for example.

In operation where loadbalancer 26 witnesses a GSN not respond to anecho message (e.g. by using a timer), table 28 may be cleanedaccordingly of tunnels associated with that non-responsive GSN. Thissame type of monitoring may also be used to determine a failure of a GSNin the network. The echoing protocol may be bi-directional and thereforemonitoring may be executed in either direction. The echoing protocol maybe on the same path as signaling communications. It may further operateon the same port but not necessarily specific to a particular networknode.

Thus, signaling parsing may be executed in order to inform loadbalancer26 of the status of all GSNs in a network. Additionally, a reloaddetection feature may be provided by this monitoring. Participating GSNelements in the network may be required by some specification to echotheir peer in order to determine path awareness. Loadbalancer 26 ispositioned in the middle of this signaling pathway and may takeadvantage of this positioning by watching, gleaning, or otherwisemonitoring the health of all GSNs in the network based on theirresponses. Such monitoring does not inhibit communication flows asloadbalancer 26 is already inspecting packets in order to verify whattype of information is being received. For example delete, create,update, echo, or any other suitable message may be generated andthereafter propagate through loadbalancer 26. Loadbalancer 26 isgenerally a focal point of the network and may accordingly view thehealth of all GSNs by gleaning information that it already receives.

FIG. 2 is a simplified block diagram of table 28 in accordance with oneembodiment of the present invention. Table 28 may be provided internalto loadbalancer 26 or provided external to loadbalancer 26 and suitablycoupled thereto. Table 28 may include an IP address column 54, a GSNtype column 56, a recovery information element (I.E.) column 58, and atimer column 60. Table 28 may be used in order to time responses tomessages from selected GSNs in communication system 10. Table 28 may besuitably created by loadbalancer 26 or appropriately configured ordesigned in accordance with particular needs.

In operation, at step A of table 28, an entry may be placed into table28 that indicates an IP address associated with a selected GSN. Theentry may include the GSN type, its associated recovery informationelement, and a timer element parameter, which may be coordinated withGTP parameters. The recovery information element may operate as a resetcounter and offer information concerning how many times a particularelement may be used. At this point, because loadbalancer 26 has seenactivity from some GSN in the network (potentially submitted pursuant toan echoing protocol) the timer may be set. The timer may be any suitabletiming element included within or accessible by table 28. In oneembodiment, the timing element is included in software withinloadbalancer 26.

When the timer expires, this may translate into the non-responsive GSNbeing dead or otherwise dysfunctional because it has not provided anappropriate response. Accordingly, table 28 may be cleaned of entriesassociated with that non-responsive GSN, i.e. those connections whichpoint to the failing GSN. Because that GSN is now gone from table 28, itmay be deemed as failed and removed from a loadbalancing algorithmprovided in loadbalancer 26 for some designated period of time before itis returned.

At step B, table 28 may be updated or an additional entry may begenerated. Where a timer associated with a selected SGSN 18 a or 18 bexpires, the only action generally required is to clean up SGSNconnections because it represents the client. The recovery informationelement may be tracked because, in cases where it changes, allconnections associated with that GSN may be removed. This representsanother feature that may be provided to table 28 in accordance with oneembodiment. An example scenario illustrating this capability is providedin FIG. 2 for purposes of teaching. Recovery information element column58 indicates a recovery information element of ‘x’ that later changes to‘z.’ Thus, when a GSN provides a communication flow that indicates arecovery information element of ‘z’ it reflects a specification definedbehavior whereby all communication tunnels may be removed because therecovery information element has changed.

Table 28 may also behave in an appropriate corresponding fashion wherean SGSN object is the first element created in table 28. Thus, whereecho activity is received from a selected SGSN 18 a or 18 b, an SGSNobject may be built first and a GGSN object built second in table 28.Two timers may then be set whereby, if the timers expire, then thecorresponding appropriate action may be taken. On an SGSN timerexpiration, all connections associated with that SGSN may be removed. Ona GGSN timer expiration, all communication sessions or tunnels may becleared that are associated with that non-responsive GGSN. In addition,loadbalancer 26 may fail the corresponding real IP address element (froma loadbalancing perspective). The real IP address element is chosen whena loadbalancing decision is executed. Additionally, loadbalancer 26 maywithhold any new connections for a failing GGSN for a specific timeinterval in accordance with particular needs.

In another example scenario, any selected GSN may send a delete requestto loadbalancer 26. The delete request may indicate to remove or to teardown designated communication sessions or tunnels. This may beeffectuated using any suitable mechanism, such as a tear down indicatorincluded in the message. Loadbalancer 26 may inspect this communicationflow and accordingly respond by tearing down appropriate tunnels andcleaning table 28. Table 28 may then be suitably flushed after anappropriate timeout period. Such a scenario addresses another problem,when objects per protocol data packet (PDP) are maintained inloadbalancer 26 and delete messages are expected in each direction.Table 28 may be implemented to flush selected objects on a GSN timeoutbecause loadbalancer 26 may not see the delete messages in cases where aselected GGSN 30 a or 30 b recognizes that a selected SGSN 18 a or 18 bis no longer responding. This may be the case where a recoveryinformation element has changed and a selected GGSN 30 a or 30 b hasrecognized this change and thus corresponding communication tunnels areappropriately removed. Thus, there is no need to offer a delete requestwhere a reload has been executed. Additional echoing messages generatedby any element in the network are problematic because they may encountercoordination problems.

FIG. 3 is a flowchart illustrating a series of example steps associatedwith a method for communicating data in communication system 10. Themethod begins at step 100, where a selected GGSN 30 a or 30 b generatesa message that propagates through loadbalancer 26. The message may bebased on some echoing protocol, data pathway awareness mechanism or anyother suitable communication flow. At step 102, loadbalancer 26 mayreceive the message and access table 28 in order to restart a timerincluded therein. The message may then pass to a selected SGSN 18 a or18 b. At step 104, loadbalancer 26 awaits a response from SGSN 18 a or18 b. Where a response is provided, loadbalancer 26 does nothing as thecommunication path is deemed active and thus no action is appropriate inthis circumstance.

Where a selected SGSN 18 a or 18 b does not respond to the messageprovided by GGSN 30 a or 30 b, at step 106 loadbalancer 26 may clear orotherwise remove all communication tunnels or sessions associated withthe non-responsive SGSN 18 a or 18 b. At step 108, loadbalancer 26 mayreceive another message from any suitable GSN provided in the network.Loadbalancer 26 may then accordingly repeat this procedure in order toaccurately identify active and inactive communication sessions andtunnels associated with GSNs in the network.

Some of the steps illustrated in FIG. 3 may be changed or deleted whereappropriate and additional steps may also be added to the flowchart.These changes may be based on specific communication architectures orparticular interfacing arrangements and configurations of associatedelements and do not depart from the scope or the teachings of thepresent invention.

Although the present invention has been described in detail withreference to IP communications, communication system 10 may be used forany tunneling protocol involving the establishment or the removal ofcommunications tunnels. Thus, any suitable communications that involvethe creation of communication pathways between network nodes may benefitfrom the teachings of the present invention. The use of end user 12 andIP communications have only been offered for purposes of teaching andshould not be construed to limit the scope of the present invention inany way.

In addition, communication system 10 may be extended to any scenario inwhich end user 12 is provided with mobility (in the context of a wiredor a wireless connection or coupling) and communicates with some type ofaccess server (e.g. a network access server (NAS), foreign agents,etc.). End user 12 may use a dedicated connection of some form or useforms of multiple access protocols where appropriate. Access may beassociated with point to point protocol (PPP) or alternatively withlayer three protocols over a layer two in accordance with particularneeds. Such an embodiment may include any suitable tunnel terminatorsand/or tunnel initiators that may be operable to communicate withloadbalancer 26.

Additionally, although communication system 10 has been described withreference to echo communications, any suitable communications flows thatpass through loadbalancer 26 may be used to glean the health ofcorresponding network elements. The use of echo communications has onlybeen used for purposes of example and should not be construed to limitthe scope of the present invention. Moreover, the use of GGSNs 30 a and30 b and SGSNs 18 a and 18 b has similarly been offered for purposes ofteaching only. Any network node that passes communication flows throughloadbalancer 26 may have its status checked in accordance with theteachings of the present invention. Loadbalancer 26 may make removaldecisions associated with communications tunnels based on the lack of aresponse offered by any network node being monitored.

Numerous other changes, substitutions, variations, alterations, andmodifications may be ascertained by those skilled in the art and it isintended that the present invention encompass all such changes,substitutions, variations, alterations, and modifications as fallingwithin the spirit and scope of the appended claims. Moreover, thepresent invention is not intended to be limited in any way by anystatement in the specification that is not otherwise reflected in theappended claims.

1. An apparatus for monitoring a state associated with a support node,comprising: a loadbalancer operable to receive one or morecommunications flows from a first support node and a second supportnode, the loadbalancer removing one or more communications tunnelsassociated with the second support node when the second support nodedoes not respond to the message communicated by the first support node,wherein the loadbalancer includes a timing element operable to provide aselected time interval in which the second support node may respond tothe message communicated by the first support node, and wherein theloadbalancer removes one or more of the communications tunnelsassociated with the second support node in response to expiration of theselected time interval, and wherein the loadbalancer includes a tableoperable to store information associated with each of the first andsecond support nodes, the table further operable to include parametersassociated with the timing element and data relating to a recoveryinformation element associated with one or more communications sessionsinitiated by each of the first and second support nodes.
 2. Theapparatus of claim 1, further comprising: an echoing protocol that isincluded in each of the first and second support nodes, wherein theechoing protocol operates to provide signaling for path awarenessbetween the first and second support nodes, the message communicated bythe first support node being part of the echoing protocol.
 3. Theapparatus of claim 1, wherein the loadbalancer removes one or more ofthe communications tunnels associated with a selected one of the firstand second support nodes when the loadbalancer detects that the recoveryinformation element associated with a selected one of the first andsecond support nodes has changed.
 4. The apparatus of claim 1, whereinthe loadbalancer is operable to detect a reload condition of the firstor second support nodes, the loadbalancer operable to remove one or morecommunications tunnels upon detection of the reload condition.
 5. Theapparatus of claim 1, wherein the loadbalancer is operable to receive adelete message from a selected one of the first and second supportnodes, the delete message indicating to remove one or more designatedcommunications tunnels associated with the selected support node, theloadbalancer operable to remove the designated communications tunnels inresponse to the delete message.
 6. A method for monitoring a stateassociated with a support node, comprising: receiving one or morecommunications flows from a first support node, wherein the firstsupport node communicates a message destined for a second support node;monitoring activity associated with the second support node; removingone or more communications tunnels associated with the second supportnode when the second support node does not respond to the messagecommunicated by the first support node; initiating a timing elementafter the message is communicated, the timing element operable toprovide a selected time interval in which the second support node mayrespond to the message communicated by the first support node; removingone or more of the communications tunnels associated with the secondsupport node upon expiration of the selected time interval; and storinginformation associated with each of the first and second support nodesin a table, the table being operable to include parameters associatedwith the timing element and data relating to a recovery informationelement associated with one or more communications sessions initiated byeach of the first and second support nodes.
 7. The method of claim 6,further comprising: providing a signaling protocol for path awarenessbetween the first and second support nodes, the message communicated bythe first support node being part of the signaling protocol.
 8. Themethod of claim 6, further comprising: monitoring the recoveryinformation element associated with the first and second support nodes;and removing one or more of the communications tunnels associated with aparticular one of the first and second support nodes in response to achange in the associated recovery information element.
 9. The method ofclaim 6, further comprising: detecting a reload condition in a selectedone of the first and second support nodes; and removing one or morecommunications tunnels associated with the selected one of the first andsecond support nodes in response to detecting the reload condition. 10.The method of claim 6, further comprising: receiving a delete messagefrom a selected one of the first and second support nodes, the deletemessage indicating to remove one or more designated communicationstunnels associated with the selected support node; and removing thedesignated communications tunnels in response to the delete message. 11.A system for monitoring a state associated with a support node,comprising: means for receiving one or more communications flows from afirst support node, wherein the first support node communicates amessage destined for a second support node; means for monitoringactivity associated with the second support node; means for removing oneor more communications tunnels associated with the second support nodewhen the second support node does not respond to the messagecommunicated by the first support node; means for initiating a timingelement after the message is communicated, the timing element operableto provide a selected time interval in which the second support node mayrespond to the message communicated by the first support node; means forremoving one or more of the communications tunnels associated with thesecond support node upon expiration of the selected time interval; andmeans for storing information associated with each of the first andsecond support nodes in a table, the table being operable to includeparameters associated with the timing element and data relating to arecovery information element associated with one or more communicationssessions initiated by each of the first and second support nodes. 12.The system of claim 11, further comprising: means for providing anechoing protocol for path awareness between the first and second supportnodes, the message communicated by the first support node being part ofthe echoing protocol.
 13. The system of claim 11, further comprising:means for monitoring the recovery information element associated withthe first and second support nodes; and means for removing one or moreof the communications tunnels associated with a selected one of thefirst and second support nodes in response to a change in the associatedrecovery information element.
 14. The system of claim 11, furthercomprising: means for detecting a reload condition in a selected one ofthe first and second support nodes; and means for removing one or morecommunications tunnels associated with the selected one of the first andsecond support nodes in response to detecting the reload condition. 15.A computer-readable storage medium having computer-executable code formonitoring a state associated with a support node, operable to: receiveone or more communications flows from a first support node, wherein thefirst support node communicates a message destined for a second supportnode; monitor activity associated with the second support node; removeone or more communications tunnels associated with the second supportnode when the second support node does not respond to the messagecommunicated by the first support node; initiate a timing element afterthe message is communicated, the timing element operable to provide aselected time interval in which the second support node may respond tothe message communicated by the first support node; remove one or moreof the communications tunnels associated with the second support nodeupon expiration of the selected time interval; and store informationassociated with each of the first and second support nodes in a table,the table being operable to include parameters associated with thetiming element and data relating to a recovery information elementassociated with one or more communications sessions initiated by each ofthe first and second support nodes.
 16. The computer-readable storagemedium of claim 15, further operable to: provide a signaling protocolfor path awareness between the first and second support nodes, themessage communicated by the first support node being part of thesignaling protocol.
 17. The computer-readable storage medium of claim15, further operable to: monitor the recovery information elementassociated with the first and second support nodes; and remove one ormore of the communications tunnels associated with a selected one of thefirst and second support nodes in response to a change in the associatedrecovery information element.
 18. An apparatus for monitoring a stateassociated with a support node, comprising: a loadbalancer operable toreceive one or more communication flows from a first support node and asecond support node, wherein the first support node communicates amessage to the second support node that propagates through theloadbalancer, the loadbalancer removing one or more communicationstunnels associated with the second support node when the second supportnode does not respond to the message communicated by the first supportnode; a timing element included within the loadbalancer and operable toprovide a selected time interval in which the second support node mayrespond to the message communicated by the first support node, whereinif the timing element expires before the second support node responds tothe message the loadbalancer removes one or more of the communicationstunnels associated with the second support node, and wherein theloadbalancer is operable to detect a reload condition of the first orsecond support nodes, the loadbalancer operable to remove one or morecommunications tunnels upon detection of the reload condition; and atable included within the loadbalancer and operable to store informationassociated with each of the first and second support nodes, the tablefurther operable to include parameters associated with the timingelement and data relating to a recovery information element associatedwith one or more communication sessions initiated by each of the firstand second support nodes.